Agent 工作流与 MCP 落地（前端应用）

目标：把 2026 年最热的 Agent（智能体） 与 MCP（模型上下文协议） 讲到“能直接当面试答案”的程度——既懂概念、又懂前端落地。

目录

• 为什么要 Agent 工作流
• Agent 到底是什么：从 Workflow 到 Agent
• Agent 核心设计模式
• 最小工作流结构
• MCP（Model Context Protocol）深入
  • MCP 是什么、解决什么问题
  • MCP 架构：Host / Client / Server
  • MCP 三种能力与传输方式
  • MCP 在前端产品中的作用
• Agent 框架现状（2026）
• 多 Agent 协作
• Agent 的记忆与上下文管理
• 工程落地要点
• 代码示例
  • 工作流步骤数据结构
  • 前端执行轨迹面板
• 失败重试流程图
• 最小验收标准

为什么要 Agent 工作流

当任务涉及“查数据 -> 计算 -> 生成 -> 校验”时，单次模型调用很难稳定。 Agent 工作流把过程拆成多步，可观测且可回放。

Agent 到底是什么：从 Workflow 到 Agent

面试常被追问“Workflow 和 Agent 有什么区别”。Anthropic 的经典划分值得记住：

• Workflow（工作流）：步骤和路径由开发者预先写死，LLM 只在固定节点上发挥（如“先检索→再总结→再校验”）。可控、可预测，适合流程清晰的任务。
• Agent（智能体）：LLM 自己决定下一步做什么、调用哪个工具、要不要继续，循环执行直到完成目标。更灵活、能处理开放任务，但更难预测、更贵、更需要护栏。

一个最小 Agent 循环（ReAct 思想）：

loop:
  思考(根据目标和已有观察，决定下一步)
  if 需要工具: 调用工具 → 拿到观察结果 → 回到 loop
  else: 输出最终答案，结束
  (加一个最大步数/超时，避免死循环)

面试一句话：“能用固定流程解决就别上 Agent。Workflow 可控成本低；Agent 适合步骤不确定、需要模型自主规划与多轮取证的开放任务，但要配预算上限、超时、权限和可观测。”

Agent 核心设计模式

四种被反复使用的模式，能说清楚就很加分：

• ReAct（Reason + Act）：思考与工具调用交替，边想边做边观察。最基础、最常用。
• Plan-and-Execute（先规划后执行）：先让模型产出完整计划，再逐步执行（可重规划）。适合多步、可拆解的任务。
• Reflection / Self-Critique（反思）：产出结果后，让模型（或另一个模型）批判并改进，循环几轮。提升质量，代价是更多 token。
• Routing（路由）：先用一个轻量模型把请求分类，路由到不同的专用 Agent / 模型 / 流程。是控成本和提质量的常用手段。

最小工作流结构

这个流程图的核心价值是把“大模型一次性完成所有事”拆成可控步骤：

• Planner 负责决定步骤
• Tool 负责执行外部能力（查、算、调接口）
• Validator 负责收尾校验，避免错误结果直接暴露给用户

这样设计后，你可以对每一步做独立重试、超时和观测，整体稳定性会明显提升。

MCP（Model Context Protocol）深入

MCP 是什么、解决什么问题

MCP 是 Anthropic 于 2024 年 11 月开源的开放协议，2025 年被 OpenAI、Google 等广泛采纳，已成为“AI 应用接外部工具/数据”的事实标准。常被比喻为“AI 应用的 USB-C 接口”。

它解决的痛点是 M×N 适配爆炸：过去每个 AI 应用要对接每个工具（数据库、GitHub、文件系统、内部 API）都得写一套专属适配，N 个应用 × M 个工具 = N×M 套胶水代码。MCP 把它变成 M+N：工具方只要实现一次 MCP Server，所有支持 MCP 的应用都能用。

MCP 架构：Host / Client / Server

• Host（宿主）：用户用的 AI 应用（Claude Desktop、Cursor、你自己的产品）。它持有 LLM，并为每个外部连接创建一个 Client。
• Client（客户端）：宿主内部与某个 Server 一对一连接的连接器，负责协议通信。
• Server（服务器）：暴露具体能力的轻量服务（文件系统、GitHub、数据库、内部 API……）。
• 通信基于 JSON-RPC 2.0。

MCP 三种能力与传输方式

MCP Server 可以向宿主暴露三类原语：

• Tools（工具）：可被模型调用的函数（查数据、发请求、改文件）——模型控制。
• Resources（资源）：可读取的上下文数据（文件、记录）——应用控制。
• Prompts（提示模板）：预设的提示词/工作流模板——用户控制（如选一个 slash 命令）。

传输方式（Transport）：

• stdio：本地进程间标准输入输出，适合本地 Server（如本地文件系统、本地工具）。
• Streamable HTTP（2025 年新标准，取代早期的 HTTP+SSE）：适合远程 Server，支持流式、可水平扩展，是远程部署的推荐方式。

面试加分：能说出“stdio 用于本地、Streamable HTTP 用于远程”，以及“早期用 HTTP+SSE 双端点，现已被 Streamable HTTP 取代”。

MCP 在前端产品中的作用

• 统一工具接入协议，减少“每个工具一套适配”；接入新工具 = 接一个 MCP Server。
• 前端可展示工具调用轨迹，提高可解释性。
• 便于权限控制和审计：所有外部能力走统一协议，方便加鉴权、脱敏、日志。
• 安全注意：MCP 让模型能调真实工具，必须防范提示注入导致的越权调用——工具调用要服务端二次鉴权、对高危操作做人工确认（human-in-the-loop）、对 Server 来源做信任管理。

前端建议展示字段：

• 工具名
• 入参摘要（脱敏）
• 执行耗时
• 成功/失败状态

Agent 框架现状（2026）

不用全记，知道“有哪些、各自定位”即可：

框架	定位	适合
Vercel AI SDK	TS/JS 全栈，前端友好	Web 应用里做带工具/流式的 Agent，前端首选
LangGraph（LangChain）	基于图的有状态 Agent 编排	复杂、可控、需要分支/循环/检查点的工作流
OpenAI Agents SDK	OpenAI 官方轻量 Agent 框架	围绕 OpenAI 生态，含 handoff、guardrails
CrewAI / AutoGen	多 Agent 协作（Python）	角色分工的多智能体系统
LlamaIndex	偏数据/RAG 的 Agent	数据密集型、RAG + Agent

前端工程师重点掌握 Vercel AI SDK（见 服务端基础能力），后端复杂编排了解 LangGraph 即可。

多 Agent 协作

当单个 Agent 的上下文/职责过载时，拆成多个各司其职的 Agent：

• Orchestrator-Worker（编排者-执行者）：一个主 Agent 拆任务、分发给多个子 Agent，再汇总。
• 角色分工：如“研究员 Agent + 写作 Agent + 审校 Agent”流水线。
• Handoff（移交）：一个 Agent 判断后把对话整体交给更专业的 Agent（如客服 → 技术支持）。

权衡：多 Agent 提升专业度和并行度，但上下文传递、成本、协调复杂度都上升。能用单 Agent + 好工具解决就别急着上多 Agent。

Agent 的记忆与上下文管理

Agent 跑多步后上下文会爆，需要主动管理（这也是 2025-2026 的热点“Context Engineering / 上下文工程”）：

• 短期记忆：当前任务的对话/中间结果，靠摘要压缩、只保留关键步骤控制长度。
• 长期记忆：跨会话的用户偏好、历史结论，通常存到向量库/数据库，需要时检索回来（本质是给 Agent 配了个 RAG）。
• 工具结果裁剪：工具返回的大段数据先摘要/截断再回注模型，避免一次塞爆上下文。
• 子 Agent 隔离：把消耗大量上下文的子任务交给独立子 Agent，只把结论返回主 Agent。

面试讲法：“Agent 的稳定性很大程度是上下文工程问题——通过摘要、长期记忆检索、工具结果裁剪，把每一步的上下文控制在‘相关且不超窗’。”

工程落地要点

• 权限：工具调用必须二次鉴权
• 超时：每步任务有独立超时与重试策略
• 日志：统一 traceId 串联 Planner、Tool、Model
• 回放：保留步骤快照，便于复盘

代码示例

工作流步骤数据结构

type StepStatus = "pending" | "running" | "success" | "failed";

type AgentStep = {
  id: string;
  name: string;
  tool?: string;
  inputSummary?: string;
  outputSummary?: string;
  status: StepStatus;
  startedAt?: number;
  endedAt?: number;
  error?: string;
};

前端执行轨迹面板

export function AgentTimeline({ steps }: { steps: AgentStep[] }) {
  return (
    <ol>
      {steps.map((s) => (
        <li key={s.id}>
          <strong>{s.name}</strong> [{s.status}]
          {s.tool ? <div>tool: {s.tool}</div> : null}
          {s.inputSummary ? <div>in: {s.inputSummary}</div> : null}
          {s.outputSummary ? <div>out: {s.outputSummary}</div> : null}
          {s.error ? <div>error: {s.error}</div> : null}
        </li>
      ))}
    </ol>
  );
}

失败重试流程图

最小验收标准

• 能展示至少两步工具调用流程
• 某一步失败时，前端可见并可重试该步
• 最终输出包含执行轨迹与关键证据